<html>
<head><meta charset="utf-8"><title>Promotion of const fn calls in const/static initializers · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html">Promotion of const fn calls in const/static initializers</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="221361952"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221361952" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221361952">(Jan 01 2021 at 18:07)</a>:</h4>
<p>The crater experiment in <a href="https://github.com/rust-lang/rust/pull/80243">https://github.com/rust-lang/rust/pull/80243</a> showed <a href="https://github.com/rust-lang/rust/pull/80243#issuecomment-751885520">2 crates</a> relying on promotion of <code>const fn</code> calls in non-trivial ways. I think a sufficiently powerful inline <code>const {}</code> with support for using generic parameters available in the context would solve both of these, but until then we have no adequate replacement. and of course even then there's the question of whether this is an acceptable breaking change.</p>
<p>There is an alternative though: we could continue promoting <code>const fn</code> calls in <code>const</code>/<code>static</code> initializers <em>only if the initializers are straight-line code</em>. This avoids situations like the following</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="n">C</span>: <span class="p">()</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="k">if</span><span class="w"> </span><span class="kc">false</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="o">&amp;</span><span class="n">failing_const_fn</span><span class="p">();</span><span class="w"> </span><span class="p">}</span><span class="w"> </span><span class="c1">// If we promote this and then evaluate the promoted, we made computing `C` fail even though it should succeed.</span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>I admit that this is a horrible hack, but it would maintain full compatibility with all code that was written before control flow was available in CTFE (and indeed, the lack of considering control flow in CTFE might have contributed to this situation arising in the first place). We could stop doing this hack in an edition; however, warning about code that would break is really hard.</p>
<p>What do y'all think?</p>
<p>(For some context on promotion, see <a href="https://github.com/rust-lang/rfcs/pull/3027">this RFC</a>)</p>



<a name="221362218"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362218" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362218">(Jan 01 2021 at 18:14)</a>:</h4>
<p>Is it possible to promote the constant, try to evaluate it and if it fails, store the result as a "const <code>poison</code>" which causes the actual build to fail only if it is accessed during evaluation of a user-level const like <code>C</code></p>



<a name="221362307"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362307" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362307">(Jan 01 2021 at 18:16)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221362218">said</a>:</p>
<blockquote>
<p>Is it possible to promote the constant, try to evaluate it and if it fails, store the result as a "const <code>poison</code>" which causes the actual build to fail only if it is accessed during evaluation of a user-level const like <code>C</code></p>
</blockquote>
<p>possible, yes. it's pretty close to what we are doing now and extremely painful.</p>



<a name="221362316"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362316" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362316">(Jan 01 2021 at 18:17)</a>:</h4>
<p>many things in the compiler become a lot simpler if "failure to evaluate const (user-defined or promoted)" can be reported as a hard error</p>



<a name="221362320"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362320" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362320">(Jan 01 2021 at 18:17)</a>:</h4>
<p>see <a href="https://github.com/rust-lang/rfcs/pull/3027">https://github.com/rust-lang/rfcs/pull/3027</a> for details</p>



<a name="221362400"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362400" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362400">(Jan 01 2021 at 18:19)</a>:</h4>
<p>as far as I am concerned, if the above option(s) all do not work, the fallback plan is "be careful to never evaluate promoteds that appear in dead code in another const"</p>



<a name="221362403"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362403" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362403">(Jan 01 2021 at 18:19)</a>:</h4>
<p>I think that's currently the case, actually, but it is more fragile than I'd like.</p>



<a name="221362454"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362454" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362454">(Jan 01 2021 at 18:20)</a>:</h4>
<p>(the crater run in <a href="https://github.com/rust-lang/rust/pull/80579">https://github.com/rust-lang/rust/pull/80579</a> will show if that fallback plan is feasible)</p>



<a name="221362686"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362686" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362686">(Jan 01 2021 at 18:26)</a>:</h4>
<p>I see <span class="user-mention silent" data-user-id="119009">eddyb</span> mentions in <a href="https://github.com/rust-lang/const-eval/issues/19">https://github.com/rust-lang/const-eval/issues/19</a> (referring to promotion of <code>let x = &amp;foo()</code> where <code>foo</code> is a failing const fn) that</p>
<blockquote>
<p>While we can demote such compile-time errors to panics by compiling them to a call to the panic machinery with the original message, this would break the backtrace and would generally require some rather complex code to support this pretty useless case.</p>
</blockquote>
<p>How important is backtrace preservation here? Are we allowed to say that this is implementation-defined?</p>



<a name="221362774"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362774" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362774">(Jan 01 2021 at 18:29)</a>:</h4>
<p>I worry that restricting the scope of const fn to just infallible ops is just going to cause delays in the rollout of const-everywhere for a use case that most people don't care about</p>



<a name="221362843"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362843" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362843">(Jan 01 2021 at 18:31)</a>:</h4>
<blockquote>
<p>How important is backtrace preservation here? Are we allowed to say that this is implementation-defined?</p>
</blockquote>
<p>Note that we are only talking about <code>const fn</code> calls <em>in const/static initializers now</em></p>



<a name="221362880"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362880" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362880">(Jan 01 2021 at 18:32)</a>:</h4>
<p>so there are no backtraces, there are just rustc diagnostics being emitted</p>



<a name="221362885"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362885" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362885">(Jan 01 2021 at 18:32)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221362774">said</a>:</p>
<blockquote>
<p>I worry that restricting the scope of const fn to just infallible ops is just going to cause delays in the rollout of const-everywhere for a use case that most people don't care about</p>
</blockquote>
<p>please re-read the above. :) nobody is proposing to perform such a restriction.</p>



<a name="221362888"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362888" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362888">(Jan 01 2021 at 18:32)</a>:</h4>
<p>the <code>&amp;</code> in my example is crucial -- it triggers promotion to static lifetime</p>



<a name="221362893"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362893" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362893">(Jan 01 2021 at 18:33)</a>:</h4>
<p>and the discussion is about not promoting any more -- my example would still compile, but the reference would not have <code>'static</code> lifetime any more</p>



<a name="221362911"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362911" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362911">(Jan 01 2021 at 18:33)</a>:</h4>
<p>probably I assumed too much context here^^ sorry for that</p>



<a name="221362912"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362912" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362912">(Jan 01 2021 at 18:33)</a>:</h4>
<p>Oh I see, I was going off your statements in the linked issues</p>



<a name="221362915"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362915" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362915">(Jan 01 2021 at 18:33)</a>:</h4>
<p>yeah those are all in the contxt of promotion</p>



<a name="221362966"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362966" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362966">(Jan 01 2021 at 18:34)</a>:</h4>
<p>so here's a self-contained example that currently builds but that I'd like to not build (and I doubt that breaks anything since control flow is still rather new):</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="n">C</span>: <span class="p">()</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="k">if</span><span class="w"> </span><span class="kc">false</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="kd">let</span><span class="w"> </span><span class="n">x</span>: <span class="kp">&amp;</span><span class="o">'</span><span class="nb">static</span> <span class="nc">_</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">&amp;</span><span class="n">failing_const_fn</span><span class="p">();</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>



<a name="221362983"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362983" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362983">(Jan 01 2021 at 18:35)</a>:</h4>
<p>if you haven't already, it's worth reading <a href="https://github.com/rust-lang/rfcs/pull/3027">https://github.com/rust-lang/rfcs/pull/3027</a> to get some context on promotion</p>



<a name="221362997"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221362997" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221362997">(Jan 01 2021 at 18:35)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221362400">said</a>:</p>
<blockquote>
<p>as far as I am concerned, if the above option(s) all do not work, the fallback plan is "be careful to never evaluate promoteds that appear in dead code in another const"</p>
</blockquote>
<p>Actually, I think there is a way to make this isomorphic to my proposal: promoted constants are evaluated lazily, to ensure the property that if they are evaluated this means that they are directly needed for a user level constant and so it's safe to report a hard error</p>



<a name="221363048"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221363048" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221363048">(Jan 01 2021 at 18:36)</a>:</h4>
<p>right, but that's annoying because for MIR optimizations, MIR printing, and maybe more purposes, it is really useful to be able to just evaluate all consts that we see</p>



<a name="221363311"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221363311" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221363311">(Jan 01 2021 at 18:42)</a>:</h4>
<p>so basically I see these options:</p>
<ul>
<li>live with the fact that promoteds in const/static initializers can fail even if they are not required for said initializer. this will require care in MIR optimizations, MIR printing, maybe more.</li>
<li>make sure that all potentally-failing promoteds in const/static initializers are required to compute the value of the const. this can happen through different means:<ul>
<li>never promote anything that might fail -- this breaks some code though (no idea how much, it's only 2 crates in crater)</li>
<li>only promote things that fail if they are in parts of the CFG that will definitely be evaluated -- that will however be rather surprising behavior, so maybe we want to do this only for old editions</li>
</ul>
</li>
</ul>



<a name="221363614"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221363614" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221363614">(Jan 01 2021 at 18:50)</a>:</h4>
<p>I don't know too much about the details of the implementation so this is probably already being done and I don't have a good sense of the code complexity cost, but it seems like you could just store a <code>Result</code> from the result of evaluating a const and propagate the error like you would a poisoned mutex when you need the value, and print it directly in the case of MIR printing (i.e. show <code>const promoted = &lt;fail&gt;</code>). It's true that "getting the value of a const" is thus fallible, but this doesn't seem particularly surprising since const evaluation is fallible in general.</p>



<a name="221363776"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221363776" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221363776">(Jan 01 2021 at 18:54)</a>:</h4>
<p>Side note (I haven't yet read this thread in full): We (<span class="user-mention" data-user-id="216206">@lcnr</span>  and I), think we may need a way to inform the <code>const_eval</code> query whether it should report a hard error and whether not, because that is needed for some situations around <code>const</code> <code>where</code> bounds. Similarly to how we do not report an error in <code>Reveal::UserFacing</code> when the error is due to layout or "too generic" errors. I was considering doing that via the <code>ParamEnv</code>, but I haven't actually come up with an actionable (and written down) plan yet.</p>



<a name="221364025"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221364025" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221364025">(Jan 01 2021 at 19:00)</a>:</h4>
<blockquote>
<p>only promote things that fail if they are in parts of the CFG that will definitely be evaluated -- that will however be rather surprising behavior, so maybe we want to do this only for old editions</p>
</blockquote>
<p>I don't think it's more suprising to users than the fact that the trailing expression of a constant also has this behaviour (and more)</p>



<a name="221364760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221364760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221364760">(Jan 01 2021 at 19:19)</a>:</h4>
<p><span class="user-mention silent" data-user-id="271719">Mario Carneiro</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221363614">said</a>:</p>
<blockquote>
<p>I don't know too much about the details of the implementation so this is probably already being done and I don't have a good sense of the code complexity cost, but it seems like you could just store a <code>Result</code> from the result of evaluating a const and propagate the error like you would a poisoned mutex when you need the value, and print it directly in the case of MIR printing (i.e. show <code>const promoted = &lt;fail&gt;</code>). It's true that "getting the value of a const" is thus fallible, but this doesn't seem particularly surprising since const evaluation is fallible in general.</p>
</blockquote>
<p>yeah this is kind of what we are doing and it leads to a lot of code complexity and bad diagnostics. the RFC has some further links.</p>
<p>const evaluation failing is not the issue. the issue is having to continue compilation "as if nothing happened" after const evaluation failed.</p>



<a name="221364781"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221364781" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221364781">(Jan 01 2021 at 19:19)</a>:</h4>
<p><span class="user-mention silent" data-user-id="124288">oli</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221363776">said</a>:</p>
<blockquote>
<p>Side note (I haven't yet read this thread in full): We (<span class="user-mention silent" data-user-id="216206">lcnr</span>  and I), think we may need a way to inform the <code>const_eval</code> query whether it should report a hard error and whether not, because that is needed for some situations around <code>const</code> <code>where</code> bounds. Similarly to how we do not report an error in <code>Reveal::UserFacing</code> when the error is due to layout or "too generic" errors. I was considering doing that via the <code>ParamEnv</code>, but I haven't actually come up with an actionable (and written down) plan yet.</p>
</blockquote>
<p>if it truly is a query parameter (so the query will be re-evaluated when errors should be shown), that seems much less painful than what we have currently.</p>



<a name="221364831"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221364831" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221364831">(Jan 01 2021 at 19:21)</a>:</h4>
<p><span class="user-mention silent" data-user-id="124288">oli</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221364025">said</a>:</p>
<blockquote>
<blockquote>
<p>only promote things that fail if they are in parts of the CFG that will definitely be evaluated -- that will however be rather surprising behavior, so maybe we want to do this only for old editions</p>
</blockquote>
<p>I don't think it's more suprising to users than the fact that the trailing expression of a constant also has this behaviour (and more)</p>
</blockquote>
<p>fair... but I think the behavior here is "even stranger". in particular if we dont want to use an expensive analysis to determine which part of the CFG will be definitely evaluated, but just check if there is any branching control-flow anywhere.</p>



<a name="221364945"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221364945" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221364945">(Jan 01 2021 at 19:24)</a>:</h4>
<p>The query parameter approach need not even evaluate the constant twice, if the "get constant or hard error" query delegates to "pure evaluate constant to Result" and turns the stored error value into a hard error</p>



<a name="221365306"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221365306" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221365306">(Jan 01 2021 at 19:34)</a>:</h4>
<p>the "error" is a lot of information, at least so far we've avoided putting that into the query cache. in particular, it contains the full CTFE backtrace.</p>



<a name="221365319"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221365319" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221365319">(Jan 01 2021 at 19:34)</a>:</h4>
<p>also, I think getting diagnostics right and non-duplicated will be rather hard with such a scheme.</p>



<a name="221365432"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221365432" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221365432">(Jan 01 2021 at 19:38)</a>:</h4>
<p>but also, this is not at all the discussion I wanted to have.^^ my question was whether making this code work</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="n">C</span>: <span class="p">()</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="kd">let</span><span class="w"> </span><span class="n">x</span>: <span class="kp">&amp;</span><span class="o">'</span><span class="nb">static</span> <span class="nc">_</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">&amp;</span><span class="n">failing_const_fn</span><span class="p">();</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>but this code fail</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="n">C</span>: <span class="p">()</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">  </span><span class="k">if</span><span class="w"> </span><span class="o">..</span><span class="p">.</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="kd">let</span><span class="w"> </span><span class="n">x</span>: <span class="kp">&amp;</span><span class="o">'</span><span class="nb">static</span> <span class="nc">_</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="o">&amp;</span><span class="n">failing_const_fn</span><span class="p">();</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>is acceptable to achieve <a href="https://github.com/rust-lang/rfcs/pull/3027">"infallible promotion"</a> or not. Now we're talking about whether we should even strive for infallible promotion. That's an interesting discussion, but a different one -- and also we have an accepted RFC saying that we should strive for infallibe promotion.</p>



<a name="221365628"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221365628" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Mario Carneiro <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221365628">(Jan 01 2021 at 19:43)</a>:</h4>
<p>At least insofar as const eval is currently "half baked" and being slowly more baked as more bits are stabilized, I don't think having a "weird" Intermediate point is necessarily a problem as long as the visible fallout from crater is not large. I don't think programmers are expecting this to have nice rules, at least if they read the discussions on const-eval :)</p>



<a name="221365938"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221365938" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221365938">(Jan 01 2021 at 19:51)</a>:</h4>
<p>Tangentially related, I think that allowing type inference on private <code>const</code>ants would become necessary in order not to lose expressive power if this promotion is removed. From my exterior and thus ignorant point of view, this seems like something not that hard to implement (this inference is currently just denied for the sake of API stability, which does not matter for non-<code>pub</code> <code>const</code>ants), and is potentially something very useful for those having to deal with this breakage (is rodrimatti on Zulip? If so, can someone ping them?). With that, a macro to have <code>const</code> blocks (thus not needing a syntax extension) would be quite trivial to write (<code>{ const IT: _ = $expr; IT }</code>)</p>



<a name="221366000"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221366000" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221366000">(Jan 01 2021 at 19:52)</a>:</h4>
<blockquote>
<p>a macro to have const blocks (thus not needing a syntax extension)</p>
</blockquote>
<p>these const blocks would not support using generic parameters of the surrounding context, so they are too weak</p>



<a name="221366974"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221366974" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221366974">(Jan 01 2021 at 20:16)</a>:</h4>
<p>Ah, true, damn</p>



<a name="221372009"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221372009" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221372009">(Jan 01 2021 at 22:25)</a>:</h4>
<blockquote>
<p>fair... but I think the behavior here is "even stranger". in particular if we dont want to use an expensive analysis to determine which part of the CFG will be definitely evaluated, but just check if there is any branching control-flow anywhere.</p>
</blockquote>
<p>Right, that is a bit annoying. I was just also thinking about closure arguments to functions which may not get called, so even if it's in the unconditional path, we can't promote it: <code>foo(|| &amp;(1/0))</code>. Though we can probably just have custom rules for closures in const context that make sure we have the good rules in there, since there is no regression issue</p>



<a name="221372470"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221372470" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221372470">(Jan 01 2021 at 22:37)</a>:</h4>
<p>So... the current possibilities that I am aware of are:</p>
<ol>
<li>keep the current status, bad because then we have fallible promotion even in dead code paths, causing errors where there are none</li>
<li>make a breaking change</li>
<li>make a small breaking change, causing inserted assertions to suddenly change what we permit in promotion </li>
<li>revert to <code>StorageDead</code>-erasing promotion instead of actually creating a separate MIR for promoteds in constants, thus always only "evaluating the promoted" when encountering it during evaluation of the constant</li>
<li>do not eagerly evaluate promoteds of constant items (what was the problem with that again except for it being inconsistent in the compiler impl)?</li>
</ol>



<a name="221398343"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221398343" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221398343">(Jan 02 2021 at 12:39)</a>:</h4>
<blockquote>
<p>Right, that is a bit annoying. I was just also thinking about closure arguments to functions which may not get called, so even if it's in the unconditional path, we can't promote it: foo(|| &amp;(1/0)). Though we can probably just have custom rules for closures in const context that make sure we have the good rules in there, since there is no regression issue</p>
</blockquote>
<p>let's make this <code>foo(|| &amp;some_fn())</code> so fit the topic. ;)<br>
that promotion candidate is not even within the const/static body any more... so I don't think we would currently promote anything here? do you have an example like this that works on stable?</p>



<a name="221398396"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221398396" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221398396">(Jan 02 2021 at 12:40)</a>:</h4>
<blockquote>
<ol>
<li>keep the current status, bad because then we have fallible promotion even in dead code paths, causing errors where there are none</li>
</ol>
</blockquote>
<p>note, the conclusion is wrong -- see <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221363311">my summary above</a>.</p>



<a name="221398404"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221398404" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221398404">(Jan 02 2021 at 12:40)</a>:</h4>
<blockquote>
<ol start="4">
<li>revert to StorageDead-erasing promotion instead of actually creating a separate MIR for promoteds in constants, thus always only "evaluating the promoted" when encountering it during evaluation of the constant</li>
</ol>
</blockquote>
<p>that's incompatible with loops, isn't it?</p>



<a name="221398415"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221398415" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221398415">(Jan 02 2021 at 12:41)</a>:</h4>
<p>I don't understand your option 3, and for 2 I am not sure which of the possibilities you mean ;)</p>



<a name="221398421"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221398421" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221398421">(Jan 02 2021 at 12:41)</a>:</h4>
<p>for 5, see <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221363311">my previous summary</a></p>



<a name="221399830"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221399830" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221399830">(Jan 02 2021 at 13:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221398396">said</a>:</p>
<blockquote>
<blockquote>
<ol>
<li>keep the current status, bad because then we have fallible promotion even in dead code paths, causing errors where there are none</li>
</ol>
</blockquote>
<p>note, the conclusion is wrong -- see <a href="#narrow/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers/near/221363311">my summary above</a>.</p>
</blockquote>
<p>My conclusion is mis-communicated, but tried to say the same thing. we emit errors for promoteds, even if said promoteds are not explicitly requested to get promoted by the user. Without promotion, the const initializer would have succeeded to evaluate, because the erroneous promoted would have never gotten visited.</p>



<a name="221399922"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221399922" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221399922">(Jan 02 2021 at 13:23)</a>:</h4>
<ol start="2">
<li>is "forbid all <code>const fn</code> in promoteds"</li>
<li>is "forbid <code>const fn</code> in promoteds that are only reached conditionally"</li>
</ol>



<a name="221399966"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Promotion%20of%20const%20fn%20calls%20in%20const/static%20initializers/near/221399966" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Promotion.20of.20const.20fn.20calls.20in.20const.2Fstatic.20initializers.html#221399966">(Jan 02 2021 at 13:24)</a>:</h4>
<blockquote>
<p>Without promotion, the const initializer would have succeeded to evaluate, because the erroneous promoted would have never gotten visited.</p>
</blockquote>
<p>this assumes we'll visit that promoted, which we can avoid (and we currently do, at least for a normal build -- not sure about <code>--emit mir</code>)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>